Фронтенд мікрофронтенд: освоєння архітектури Module Federation

У сучасному світі веброзробки, що стрімко розвивається, створення та підтримка великомасштабних фронтенд-додатків може ставати дедалі складнішою. Традиційні монолітні архітектури часто призводять до таких проблем, як роздутий код, повільний час збирання та труднощі з незалежним розгортанням. Мікрофронтенди пропонують рішення, розбиваючи фронтенд на менші, більш керовані частини. Ця стаття детально розглядає Module Federation — потужну техніку для впровадження мікрофронтендів, досліджуючи її переваги, архітектуру та практичні стратегії реалізації.

Що таке мікрофронтенди?

Мікрофронтенди — це архітектурний стиль, за якого фронтенд-додаток розкладається на менші, незалежні та розгортані одиниці. Кожен мікрофронтенд зазвичай належить окремій команді, що забезпечує більшу автономію та швидші цикли розробки. Цей підхід віддзеркалює архітектуру мікросервісів, яка зазвичай використовується на бекенді.

Ключові характеристики мікрофронтендів:

• Незалежне розгортання: Кожен мікрофронтенд можна розгортати незалежно, не впливаючи на інші частини додатку.
• Автономність команди: Різні команди можуть володіти та розробляти різні мікрофронтенди, використовуючи власні технології та робочі процеси.
• Технологічна різноманітність: Мікрофронтенди можуть бути створені з використанням різних фреймворків та бібліотек, що дозволяє командам обирати найкращі інструменти для роботи.
• Ізоляція: Мікрофронтенди повинні бути ізольовані один від одного, щоб запобігти каскадним збоям та забезпечити стабільність.

Навіщо використовувати мікрофронтенди?

Впровадження архітектури мікрофронтендів пропонує декілька значних переваг, особливо для великих і складних додатків:

• Покращена масштабованість: Розбиття фронтенду на менші одиниці полегшує масштабування додатку за потреби.
• Швидші цикли розробки: Незалежні команди можуть працювати паралельно, що призводить до швидшої розробки та циклів випуску.
• Збільшена автономність команди: Команди мають більше контролю над своїм кодом і можуть приймати рішення незалежно.
• Простіше обслуговування: Менші кодові бази легше підтримувати та налагоджувати.
• Технологічна незалежність: Команди можуть обирати найкращі технології для своїх конкретних потреб, що дозволяє впроваджувати інновації та експериментувати.
• Зменшений ризик: Розгортання стають меншими та частішими, що зменшує ризик масштабних збоїв.

Вступ до Module Federation

Module Federation — це функція, представлена у Webpack 5, яка дозволяє JavaScript-додаткам динамічно завантажувати код з інших додатків під час виконання. Це уможливлює створення справді незалежних та компонованих мікрофронтендів. Замість того, щоб збирати все в один пакет, Module Federation дозволяє різним додаткам ділитися та споживати модулі один одного, ніби вони були локальними залежностями.

На відміну від традиційних підходів до мікрофронтендів, які покладаються на iframe або вебкомпоненти, Module Federation забезпечує більш плавний та інтегрований досвід для користувача. Це дозволяє уникнути надлишкових витрат на продуктивність та складності, пов'язаних з іншими техніками.

Як працює Module Federation

Module Federation працює за концепцією "експонування" та "споживання" модулів. Один додаток ("хост" або "контейнер") може експонувати модулі, тоді як інші додатки ("віддалені") можуть споживати ці експоновані модулі. Ось розбивка процесу:

1. Експонування модулів: Мікрофронтенд, налаштований як "віддалений" додаток у Webpack, експонує певні модулі (компоненти, функції, утиліти) через файл конфігурації. Ця конфігурація визначає модулі, якими потрібно поділитися, та їхні відповідні точки входу.
2. Споживання модулів: Інший мікрофронтенд, налаштований як "хост" або "контейнер", оголошує віддалений додаток як залежність. Він вказує URL-адресу, за якою можна знайти маніфест федерації модулів віддаленого додатку (невеликий JSON-файл, що описує експоновані модулі).
3. Розв'язання під час виконання: Коли хост-додатку потрібно використати модуль з віддаленого додатку, він динамічно завантажує маніфест федерації модулів віддаленого додатку. Потім Webpack розв'язує залежність модуля та завантажує необхідний код з віддаленого додатку під час виконання.
4. Спільне використання коду: Module Federation також дозволяє спільне використання коду між хост- та віддаленими додатками. Якщо обидва додатки використовують однакову версію спільної залежності (наприклад, React, lodash), код буде спільним, що дозволяє уникнути дублювання та зменшити розмір пакетів.

Налаштування Module Federation: практичний приклад

Проілюструймо Module Federation на простому прикладі з двома мікрофронтендами: a "Каталог товарів" та a "Кошик покупок". Каталог товарів експонуватиме компонент зі списком товарів, який Кошик покупок буде споживати для відображення пов'язаних товарів.

Структура проєкту

  
  micro-frontend-example/
    product-catalog/
      src/
        components/
          ProductList.jsx
        index.js
        webpack.config.js
    shopping-cart/
      src/
        components/
          RelatedProducts.jsx
        index.js
        webpack.config.js
  

Каталог товарів (віддалений)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... інші конфігурації webpack
    plugins: [
      new ModuleFederationPlugin({
        name: 'product_catalog',
        filename: 'remoteEntry.js',
        exposes: {
          './ProductList': './src/components/ProductList',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

Пояснення:

• name: Унікальна назва віддаленого додатку.
• filename: Назва файлу точки входу, який буде експоновано. Цей файл містить маніфест федерації модулів.
• exposes: Визначає, які модулі будуть експоновані цим додатком. У цьому випадку ми експонуємо компонент `ProductList` з `src/components/ProductList.jsx` під назвою `./ProductList`.
• shared: Вказує залежності, які мають бути спільними для хост- та віддалених додатків. Це вкрай важливо для уникнення дублювання коду та забезпечення сумісності. `singleton: true` гарантує, що завантажується лише один екземпляр спільної залежності. `eager: true` завантажує спільну залежність одразу, що може покращити продуктивність. `requiredVersion` визначає допустимий діапазон версій для спільної залежності.

src/components/ProductList.jsx

  
  import React from 'react';

  const ProductList = ({ products }) => (
    

      {products.map((product) => (
        
{product.name} - ${product.price}
      ))}
    
  );

  export default ProductList;
  

Кошик покупок (хост)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... інші конфігурації webpack
    plugins: [
      new ModuleFederationPlugin({
        name: 'shopping_cart',
        remotes: {
          product_catalog: 'product_catalog@http://localhost:3001/remoteEntry.js',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

Пояснення:

• name: Унікальна назва хост-додатку.
• remotes: Визначає віддалені додатки, з яких цей додаток буде споживати модулі. У цьому випадку ми оголошуємо віддалений додаток з назвою `product_catalog` та вказуємо URL-адресу, за якою можна знайти його файл `remoteEntry.js`. Формат: `remoteName: 'remoteName@remoteEntryUrl'`.
• shared: Подібно до віддаленого додатку, хост-додаток також визначає свої спільні залежності. Це гарантує, що хост- та віддалені додатки використовують сумісні версії спільних бібліотек.

src/components/RelatedProducts.jsx

  
  import React, { useEffect, useState } from 'react';
  import ProductList from 'product_catalog/ProductList';

  const RelatedProducts = () => {
    const [products, setProducts] = useState([]);

    useEffect(() => {
      // Отримання даних про пов'язані товари (наприклад, з API)
      const fetchProducts = async () => {
        // Замініть на вашу реальну кінцеву точку API
        const response = await fetch('https://fakestoreapi.com/products?limit=3');
        const data = await response.json();
        setProducts(data);
      };

      fetchProducts();
    }, []);

    return (
      

        
Related Products
        {products.length > 0 ?  : 
Loading...
}
      
    );
  };

  export default RelatedProducts;
  

Пояснення:

• import ProductList from 'product_catalog/ProductList'; Цей рядок імпортує компонент `ProductList` з віддаленого додатку `product_catalog`. Синтаксис `remoteName/moduleName` вказує Webpack завантажити модуль із зазначеного віддаленого додатку.
• Потім компонент використовує імпортований `ProductList` для відображення пов'язаних товарів.

Запуск прикладу

1. Запустіть додатки "Каталог товарів" і "Кошик покупок" за допомогою їхніх відповідних серверів розробки (наприклад, `npm start`). Переконайтеся, що вони працюють на різних портах (наприклад, "Каталог товарів" на порту 3001, а "Кошик покупок" на порту 3000).
2. Перейдіть до додатку "Кошик покупок" у вашому браузері.
3. Ви повинні побачити розділ "Пов'язані товари", який рендериться компонентом `ProductList` з додатку "Каталог товарів".

Просунуті концепції Module Federation

Окрім базового налаштування, Module Federation пропонує кілька просунутих функцій, які можуть покращити вашу архітектуру мікрофронтендів:

Спільне використання коду та версіонування

Як показано в прикладі, Module Federation дозволяє спільне використання коду між хост- та віддаленими додатками. Це досягається за допомогою опції конфігурації `shared` у Webpack. Вказуючи спільні залежності, ви можете уникнути дублювання коду та зменшити розмір пакетів. Правильне версіонування спільних залежностей є вирішальним для забезпечення сумісності та запобігання конфліктам. Семантичне версіонування (SemVer) є широко використовуваним стандартом для версіонування програмного забезпечення, що дозволяє визначати сумісні діапазони версій (наприклад, `^17.0.0` дозволяє будь-яку версію, більшу або рівну 17.0.0, але меншу за 18.0.0).

Динамічні віддалені модулі

У попередньому прикладі URL-адреса віддаленого модуля була жорстко закодована у файлі `webpack.config.js`. Однак у багатьох реальних сценаріях вам може знадобитися динамічно визначати URL-адресу віддаленого модуля під час виконання. Цього можна досягти за допомогою конфігурації віддалених модулів на основі промісів:

  
  // webpack.config.js
  remotes: {
    product_catalog: new Promise(resolve => {
      // Отримати URL-адресу віддаленого модуля з файлу конфігурації або API
      fetch('/config.json')
        .then(response => response.json())
        .then(config => {
          const remoteUrl = config.productCatalogUrl;
          resolve(`product_catalog@${remoteUrl}/remoteEntry.js`);
        });
    }),
  },
  

Це дозволяє налаштовувати URL-адресу віддаленого модуля залежно від середовища (наприклад, розробка, тестування, продакшн) або інших факторів.

Асинхронне завантаження модулів

Module Federation підтримує асинхронне завантаження модулів, що дозволяє завантажувати модулі на вимогу. Це може покращити початковий час завантаження вашого додатку, відкладаючи завантаження некритичних модулів.

  
  // RelatedProducts.jsx
  import React, { Suspense, lazy } from 'react';

  const ProductList = lazy(() => import('product_catalog/ProductList'));

  const RelatedProducts = () => {
    return (
      

        
Related Products
        Loading...
}>
          
        
      
    );
  };
  

Використовуючи `React.lazy` та `Suspense`, ви можете асинхронно завантажувати компонент `ProductList` з віддаленого додатку. Компонент `Suspense` надає запасний інтерфейс користувача (наприклад, індикатор завантаження), поки модуль завантажується.

Федеративні стилі та ресурси

Module Federation також можна використовувати для спільного використання стилів та ресурсів (асетів) між мікрофронтендами. Це може допомогти підтримувати єдиний вигляд та відчуття у вашому додатку.

Щоб ділитися стилями, ви можете експонувати CSS-модулі або стилізовані компоненти з віддаленого додатку. Щоб ділитися ресурсами (наприклад, зображеннями, шрифтами), ви можете налаштувати Webpack для копіювання ресурсів у спільне місце, а потім посилатися на них з хост-додатку.

Найкращі практики для Module Federation

При впровадженні Module Federation важливо дотримуватися найкращих практик для забезпечення успішної та підтримуваної архітектури:

• Чітко визначайте межі: Чітко визначайте межі між мікрофронтендами, щоб уникнути тісного зв'язку та забезпечити незалежне розгортання.
• Встановлюйте протоколи комунікації: Визначте чіткі протоколи комунікації між мікрофронтендами. Розгляньте можливість використання шин подій, спільних бібліотек керування станом або власних API.
• Ретельно керуйте спільними залежностями: Ретельно керуйте спільними залежностями, щоб уникнути конфліктів версій та забезпечити сумісність. Використовуйте семантичне версіонування та розгляньте можливість використання інструментів керування залежностями, таких як npm або yarn.
• Впроваджуйте надійну обробку помилок: Впроваджуйте надійну обробку помилок, щоб запобігти каскадним збоям та забезпечити стабільність вашого додатку.
• Моніторте продуктивність: Моніторте продуктивність ваших мікрофронтендів для виявлення вузьких місць та оптимізації продуктивності.
• Автоматизуйте розгортання: Автоматизуйте процес розгортання для забезпечення послідовних та надійних розгортань.
• Використовуйте єдиний стиль кодування: Забезпечуйте єдиний стиль кодування у всіх мікрофронтендах для покращення читабельності та підтримуваності. У цьому можуть допомогти такі інструменти, як ESLint та Prettier.
• Документуйте свою архітектуру: Документуйте архітектуру ваших мікрофронтендів, щоб усі члени команди розуміли систему та як вона працює.

Module Federation у порівнянні з іншими підходами до мікрофронтендів

Хоча Module Federation є потужною технікою для реалізації мікрофронтендів, це не єдиний підхід. Інші популярні методи включають:

• Iframes: Iframes забезпечують сильну ізоляцію між мікрофронтендами, але їх може бути важко безшовно інтегрувати, і вони можуть мати додаткові витрати на продуктивність.
• Вебкомпоненти: Вебкомпоненти дозволяють створювати повторно використовувані елементи інтерфейсу, які можна використовувати в різних мікрофронтендах. Однак їх реалізація може бути складнішою, ніж у Module Federation.
• Інтеграція на етапі збирання: Цей підхід передбачає збирання всіх мікрофронтендів в один додаток під час збирання. Хоча це може спростити розгортання, це зменшує автономію команди та збільшує ризик конфліктів.
• Single-SPA: Single-SPA — це фреймворк, який дозволяє об'єднувати кілька односторінкових додатків в один. Він забезпечує більш гнучкий підхід, ніж інтеграція на етапі збирання, але може бути складнішим у налаштуванні.

Вибір підходу залежить від конкретних вимог вашого додатку, а також розміру та структури вашої команди. Module Federation пропонує хороший баланс між гнучкістю, продуктивністю та простотою використання, що робить його популярним вибором для багатьох проєктів.

Реальні приклади використання Module Federation

Хоча конкретні реалізації в компаніях часто є конфіденційними, загальні принципи Module Federation застосовуються в різних галузях та сценаріях. Ось кілька потенційних прикладів:

• Платформи електронної комерції: Платформа електронної комерції може використовувати Module Federation для розділення різних секцій вебсайту, таких як каталог товарів, кошик, процес оформлення замовлення та керування обліковими записами користувачів, на окремі мікрофронтенди. Це дозволяє різним командам працювати над цими секціями незалежно та розгортати оновлення, не впливаючи на решту платформи. Наприклад, команда в *Німеччині* може зосередитися на каталозі товарів, тоді як команда в *Індії* керує кошиком.
• Додатки для фінансових послуг: Додаток для фінансових послуг може використовувати Module Federation для ізоляції чутливих функцій, таких як торгові платформи та управління рахунками, в окремі мікрофронтенди. Це підвищує безпеку та дозволяє проводити незалежний аудит цих критичних компонентів. Уявіть, що команда в *Лондоні* спеціалізується на функціях торгової платформи, а інша команда в *Нью-Йорку* займається управлінням рахунками.
• Системи управління контентом (CMS): CMS може використовувати Module Federation, щоб дозволити розробникам створювати та розгортати власні модулі як мікрофронтенди. Це забезпечує більшу гнучкість та кастомізацію для користувачів CMS. Команда в *Японії* може створити спеціалізований модуль галереї зображень, тоді як команда в *Бразилії* створює розширений текстовий редактор.
• Додатки для охорони здоров'я: Медичний додаток може використовувати Module Federation для інтеграції різних систем, таких як електронні медичні картки (EHR), портали для пацієнтів та системи білінгу, як окремі мікрофронтенди. Це покращує сумісність та полегшує інтеграцію нових систем. Наприклад, команда в *Канаді* може інтегрувати новий модуль телемедицини, тоді як команда в *Австралії* зосереджується на покращенні досвіду роботи з порталом для пацієнтів.

Висновок

Module Federation надає потужний та гнучкий підхід до впровадження мікрофронтендів. Дозволяючи додаткам динамічно завантажувати код один одного під час виконання, він уможливлює створення справді незалежних та компонованих фронтенд-архітектур. Хоча це вимагає ретельного планування та реалізації, переваги підвищеної масштабованості, швидших циклів розробки та більшої автономії команди роблять його переконливим вибором для великих та складних вебдодатків. Оскільки ландшафт веброзробки продовжує розвиватися, Module Federation готовий відігравати все більш важливу роль у формуванні майбутнього архітектури фронтенду.

Розуміючи концепції та найкращі практики, викладені в цій статті, ви можете використовувати Module Federation для створення масштабованих, підтримуваних та інноваційних фронтенд-додатків, які відповідають вимогам сучасного швидкоплинного цифрового світу.